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MECHANISMS FOR THE ADDITION OF NEW 
SYSTEM INFORMATION BLOCK (SIB) TYPES IN 
TELECOMMUNICATION MESSAGE(S) 



[0001]FIELD OF THE INVENTION 

[0002] The present invention relates to a specific protocol extension scenario for 
telecommunications, namely the addition of a new system information block (SIB) type 
to message(s) transmitted in cellular applications such as, for example, a cellular 
network that uses Wideband Code Division Multiple Access (W-CDMA). 

[0003] RELATED ART AND OTHER CONSIDERATIONS 

[0004] In a typical cellular radio system, wireless user equipment units (UEs) 
communicate via a radio access network (RAN) to one or more core networks (CN). 
The user equipment units (UEs) can be mobile stations such as mobile telephones 
("cellular" telephones) and laptops with mobile termination, and thus can be, for 
example, portable, pocket, hand-held, computer-included, or car-mounted mobile 
devices which communicate voice and/or data with radio access network. 
Alternatively, the wireless user equipment units can be fixed wireless devices, e.g., 
fixed cellular devices/terminals which are part of a wireless local loop or the like. 

[0005] The radio access network (RAN) covers a geographical area which is divided 
into cell areas, with each cell area being served by a base station. A cell is a 
geographical area where radio coverage is provided by the radio base station equipment 
at a base station site. Each cell is identified by a unique identity, which is broadcast in 
the cell. The base stations communicate over the air interface (e.g., radio frequencies) 
with the user equipment units (UE) within range of the base stations. In the radio 
access network, several base stations are typically connected (e.g., by landlines or 
microwave) to a radio network controller (RNC). The radio network controller, also 
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sometimes termed a base station controller (BSC), supervises and coordinates various 
activities of the plural base stations connected thereto. The radio network controllers 
are typically connected to one or more core networks. The core network has various 
service domains, with an RNC having an interface to these domains. 

5 [0006] One example of a radio access network is the Universal Mobile 

Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The 
UMTS is a third generation system which in some respects builds upon the radio access 
technology known as Global System for Mobile communications (GSM) developed in 
Europe. The UTRAN (UMTS Terrestrial Radio Access Network) is the part of the 

10 network that is responsible for the radio transmission and control of the radio 

connection. The UTRAN is essentially a radio access network providing wideband 
code division multiple access (WCDMA) to user equipment units (UEs). The Third 
Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN 
and GSM-based radio access network technologies, and has developed certain technical 

15 specifications (TS) relating to standardization efforts. 

[0007] Other types of telecommunications systems which encompass radio access 
networks include the following: Advance Mobile Phone Service (AMPS) system; the 
Narrowband AMPS system (NAMPS); the Total Access Communications System 
(TACS); the Personal Digital Cellular (PDS) system; the United States Digital 
20 Cellular (USDC) system; and the code division multiple access (CDMA) system 
described in EIA/TIA IS-95. 

[0008] There are several interfaces of interest in the UTRAN. The interface between 
the radio network controllers (RNCs) and the core network(s) is termed the "Iu" 
interface. The interface between a radio network controller (RNC) and its base stations 

25 (BSs) is termed the "Iub" interface. The interface between the user equipment unit 
(UE) and the base stations is known as the "air interface" or the "radio interface" or 
"Uu interface". In some instances, a connection involves both a Serving RNC (SRNC) 
and a drift RNC (DRNC), with the SRNC controlling the connection but with one or 
more diversity legs of the connection being handling by the DRNC. An Inter-RNC 

30 transport link can be utilized for the transport of control and data signals between 
Serving RNC and a Drift RNC. An interface between radio network controllers (e.g., 
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between a Serving RNC [SRNC] and a Drift RNC PRNC]) is termed the "Iur" 
interface. 

[0009] The RNS (Radio Network Subsystem) controls a number of Base Stations in the 
radio access network. As part of the RNS, the radio network controller (RNC) controls 
5 the UTRAN. In fulfilling its control role, the RNC (Radio Network Controller) 
controls radio resources and radio connectivity within a set of cells. Such resources 
managed by the RNC include (among others) the downlink (DL) power transmitted by 
the base stations; the uplink (UL) interference perceived by the base stations; and the 
hardware situated at the base stations. 

10 [00010] The topology of a radio access network can also be conceptualized in 
areas or units larger than cells. Taking the UTRAN as an example radio access 
network, a UTRAN Routing Area (URA ) is a geographical area comprising one or 
more cells. Each URA is identified by a unique identity which is broadcast in all cells 
belonging to the URA. A URA can comprise cells controlled by more than one RNC. 

15 A URA with more cells in more than one RNC is overlapping between the RNCs, i.e. 
an overlapping URA. 

[0001 1] As another example from UTRAN, a Location Area (LA) is a 
geographical area comprising one or more cells. Each LA is identified by a unique 
identity sent on the broadcast channel, in the same way as the URA. However, a 

20 location area is used by the core network to track the location of the UE (in idle mode 
and in connected mode), while the URA is used by the radio access network to track the 
location of the UE in connected mode. Typically, a location area is geographically 
larger than a URA. To each location area there is one of several RNCs having cells in 
that particular location area. A relationship between location area and RNC is stored in 

25 the core network. 

[00012] Radio access networks typically have a particular signalling protocol employed 
between the radio access network and the user equipment unit to support the 
management of radio resources. For example, UTRAN has its Radio Resource Control 
(RRC) layer 3 signalling protocol. A user equipment unit in the RRC protocol operates 
30 in a state model conceptualized as having two modes: an Idle Mode and a Connected 
Mode. The Idle Mode is entered after power on. In Idle Mode there is no connection 
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between the user equipment unit (UE) and the UTRAN. The least active UEs operate 
in the idle mode, in which UTRAN is unaware of the presence of the UE. The core 
network (CN), however, is aware of the Location Area (LA)/ Routing Area (RA) in 
which the UE is located. The UE also informs the CN of changes in LA/ RA. 
5 Furthermore, in case an incoming call is to be established, the CN initiates paging in all 
cells comprising the LA/ RA in which the UE is registered. 

[00013] When an RRC connection is established, the user equipment unit (UE) is 
assigned a U-RNTI and the user equipment unit (UE) enters Connected Mode* In 
Connected Mode, the RNC in charge of the RRC connection for this UE is denoted as 
the Serving RNC (SRNC). As illustrated by Fig. X, within Connected Mode there are 
four different states (in order of increasing activity level): URA J?CH; CELL_PCH; 
CELL_FACH; and CELL_DCH. In the first two states the UE is inactive, in the 
URA_PCH state the UTRAN knows the UE position at the UTRAN Routing Area 
(URA) level while in CELL_DCH UTRAN knows the UE position at the cell level. In 
the CELL_FACH state the UE is active but operates on a common channel, which is a 
channel shared with other UEs. In the CELL_DCH state the UE operates on a 
dedicated channel which is allocated only for that UE. 

[00014] In the CELLJDCH state the UTRAN controls the mobility of the UE, i.e. it 
orders the UE to perform measurements and based on , e.g., those measurements; 
20 performs such activities as, e.g., moving the UE to another cell, adding or removing 
cells from the active set (i.e., the set of cells actively used in the RRC connection). In 
the other states however, the UE normally decides which cell to move to, although this 
cell re-selection process is influenced by parameters provided by the network. 

[00015] To facilitate operations such as those described above, the UTRAN broadcasts 
25 or transmits certain "system information" over the air interface which may be relevant 
for a large number of UEs in a cell. The system information includes information 
and/or parameters which are formatted into information elements (EEs). The parameters 
of the information elements (IEs) are utilized for various purposes such as, e.g., to 
control the cell re-selection procedure for a UE. The broadcast of system information 
30 in general is described, e.g., in Technical Specification 3GPP TS 25.331 V3.17.0 

(2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999), e.g., 
§§8.1etseq. 
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[00016] For various reasons some parameters (IEs) of the system information need to 
be broadcast more often than other parameters (IEs). For example, some of the 
parameters (EEs) need to be broadcast more frequently because, e.g., they affect the 
access delay or because the information changes rapidly. On the other hand, other 
5 system information is broadcast less frequently to spare or save the limited radio 
resources. 

[00017] To facilitate different scheduling of system information, the system 
information (e.g., the system information message) is partitioned into a number of 
different types of system information blocks (SIBs). This partitioning of the system 
10 information into system information blocks (SIBs) permits, among other things, 

transmission of each type of SIB to be scheduled independently and at different time 
intervals to accomplish the aforementioned objectives. The different types of system 
information blocks are distinguished by means of a "SIB type" information element. 

[00018] Thus, the system information elements are broadcast in system information 
15 blocks. A system information block groups together system information elements of 
the same nature. Different system information blocks may have different 
characteristics, e.g., regarding their repetition rate and the requirements of the UEs to 
re-read the system information blocks. 

[00019] As discussed in Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), 
20 Radio Resource Control (RRC) Protocol Specification (Release 1999), e.g., §8.1.1,1.1, 
the system information is organized into a tree. In this tree organization scheme, a 
"master information block" (MIB) gives references and scheduling information to a 
number of system information blocks in a cell. The system information blocks (SIBs) 
contain the actual system information. The master information block may optionally 
25 also contain reference and scheduling information to one or two "scheduling blocks". 
These scheduling blocks give references and scheduling information for additional 
system information blocks. Scheduling information for a system information block 
may only be included in either the master information block or one of the scheduling 
blocks. 

30 [00020] Typically, a channel known as the broadcast channel is used to transfer system 
information and thus to carry the system information blocks (SIBs). Unfortunately, the 
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broadcast channel (BCCH) only supports transfer of data units of a fixed size. This can 
be a problem since many of the system information blocks (SIBs) have a size which 
exceeds the fixed size of the BCCH. Therefore, in order to support system information 
blocks with a size exceeding the BCCH limit, a technique known as segmentation is 

5 used. Furthermore, to use the broadcast channel (BCCH) efficiently, a concatenation 
mechanism is provided. These two mechanisms basically operates as follows: (a) 
system information blocks may be split into a number of different segments, and (b) a 
number of segments may be concatenated. The concatenation of a number of segments 
is called a system information message. The segmentation and concatenation of 

10 segments for system information blocks (SIBs) are described, e.g., in Technical 
Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) 
Protocol Specification (Release 1999), e.g., §8.1.1.1.3. The entire Technical 
Specification 3GPP TS 25.331 V3.17.0 (2003-12) is incorporated herein by reference. 

[00021] As indicated above, information about which SIB is broadcast at a certain 
15 moment is not only provided within the corresponding segments of a system 

information block (SIB) but also within the scheduling information that is included in 
the Master Information Block (MIB) and/or one or more Scheduling Blocks (SBs). 
Although this facility introduces some redundancy, it also makes the segmentation 
more robust and makes it possible for the UE to decode SIBs even when its scheduling 
20 information is not yet available. 

[00022] The signalling specified in the existing RRC protocol (e.g., Technical 
Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) 
Protocol Specification (Release 1999)) also provides two specific mechanisms for the 
possibility of future extensions or modifications to signalling messages. These future 

25 extension mechanisms are described, e.g., in RRC protocol (e.g., Technical 

Specification 3GPPTS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) 
Protocol Specification (Release 1999) §10.1.1 et seq. Briefly, one of the mechanisms 
for future extension of all messages is the critical extension mechanism. The critical 
message extension mechanism involves the definition of a new version of the message. 

30 In the new version of the message the transfer syntax may be completely different from 
the previous version of the message, except for the initial part that indicates the version. 
The second of the future extension mechanisms is the non-critical message extension. 
When the non-critical message extension is used, the transfer syntax of the existing 
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message is just extended with new information. In the non-critical message extension 
case old receivers will still recognize the entire message apart from the newly 
introduced extensions. 

[00023] Since system information messages are broadcast generally, they cannot be 
5 directed only towards mobiles that support a certain protocol extension. 

Consequentially, to maintain backward compatibility, only the non-critical extension 
message mechanism can be used for system information. Furthermore, for system 
information the extension mechanism has been defined only at the level of the system 
information blocks. This means that future extension is neither possible at the level of 
io the segments nor at the level of the system information messages. 

[00024] In the RRC protocol, the transfer syntax specifies the range of possible 
information element values for parameters. In some cases this range includes a 
number of spare values that are reserved for future extension. This is also the case for 
the message type information element. The RRC protocol (TS 25.331) explicitly 
15 specifies that the UE shall ignore broadcast messages (message sent on BCCH) having 
a type which it does not comprehend. In other words, if the UE receives an RRC 
message on the BCCH, PCCH, CCCH or SHCCH with a message type not defined for 
the logical channel type the message was received on, the UE shall ignore the message. 

In the future there will certainly be a need to introduce new system information block 
20 types within the Radio Resource Control (RRC) protocol as defined within 3GPP TS 
25.331. Such new block types will be needed when, in future protocol versions, the 
system information is extended with information that needs to be scheduled 
independently using the currently defined flexible scheduling mechanism. One way to 
add new system information parameters (which will be defined in future) could be to 
25 add the new parameters to existing system information blocks. However, simply 
adding new parameters to existing system information blocks (SIBs) may be 
problematic if the new parameters have distinct scheduling requirements and/or specific 
requirements concerning their validity that is different from the system information 
blocks (SIBs) where they are added. Therefore, most likely it will be preferable to 
30 create one or more new system information blocks for these parameters. Creating a 
new system information block (SIB) will involve creating a new "SIB type 1 ' value for 
the new system information block (SIB), with each newly created SIB type thereby 
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using one of the limited number of spare values defined for the "SIB type" information 
element. 

[00025] Moreover, to complicate matters, the "SIB type" information element is 
actually included in a number of hosting information elements, and the number of spare 
values reserved for future extension is not necessarily uniform among the hosting 
information elements (note that one information element can be a component or 
information element of another (host) information element ). For example, the 
information element "SIB type" is used in different segments, such as the information 
elements "Complete SIB" & "Complete SIB (short)". Currently, thirty two values 
have been defined for this "SIB type" when included in these different information 
element s, of which only two of the values are spare values. On the other hand, the 
information element "SIB and SB Type" is used in IE "References to other system 
information blocks and scheduling blocks", which is included in the MIB. Currently 
thirty two values have been defined for this EE, of which three are spare values. Yet 
differently, the information element "SIB type SIBs only" is used in the two 
information elements known as "SCCPCH Information for FACH" and "References to 
other system information blocks". Currently thirty two values have been defined for 
this ie , of which five values are spare values. Hence, as seen from the foregoing, the 
number of spare values is not consistent among the host information elements. 

[00026] One possible way to extend the SIB type is as follows: (1) use the last spare 
value to indicate that the SIB type is extended; and (2) add a non critical extension to 
the message in order to support further extensions in future. For example, if it is 
desired to add support for an additional seven SIB types, one would need to add a three 
-bit field. In this case the first thirty one SIB types can be signalled by means of the 
original SIB type, while SIB type 31 up to 37 can be supported by the non-critical 
extension. Value 7 (' 1 1 l'B) of the non-critical extension would then be reserved for 
further extensions. 

[00027] However, as mentioned before, future extension for system information is only 
possible at the level of the system information blocks. This means that the approach 
proposed in the preceding paragraph only works effectively for the SIB type 
information elements that are contained in system information blocks. For the SIB type 
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information elements that are included in the segments and in the system information 
message another approach would clearly be needed. 

[00028] Thus, at present it is only possible to add one additional SIB using the current 
extension mechanism. Moreover, due to the lack of extension possibilities at the level 
5 of the SYSTEM INFORMATION message and the level of the segments, it is not 
apparent how additional system information blocks (SEBs) should be introduced. 

[00029] What is needed, therefore, and an object of the present invention, is techniques 
or mechanisms for adding additional types of system information blocks (SIBs) to 
telecommunications transmissions. 

s 

io BRIEF SUMMARY 

[00030] Described herein are embodiments of nodes of a telecommunications network 
which prepare network system information for transmission across an air interface to a 
user equipment unit; methods of operating such node; and, embodiments of user 
equipment units which receive and process the system information. 

15 [00031] The system information includes a system information block type which is 
included in protocol blocks. The protocol blocks include a system information block 
and a referencing block (1 10). In accordance with one particular kind of protocol, i.e., 
Radio Resource Control (RRC) protocol, the referencing block (1 10) is one or both of a 
master information block and a scheduling block. The protocol blocks in which the 

20 system information is included have a system information block type field. The 
information block type field includes a system information block type value which 
corresponds to the system information block type. The system information block can 
comprise one or more segments. 

[00032] The node embodiments include a system information extension utility function 
25 which is arranged to facilitate the use of extended system information block types, e.g., 
the use of system information block type values which are outside a range of nominal 
system information block type values. 

[00033] In one mode and method, the system information extension utility function is 
arranged and functions to accomplish the following: (1) include a first system 
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information block type extension indicator in the system information block type field of 
the referencing block when the system information block type for a system information 
block referenced by the referencing block does not have a system information block 
type value in a nominal range of system information block type values; (2) include a 

5 first system information block type extension field in the referencing block; (3) 

include, in the first system information block type extension field, a system information 
block type extension value which indicates a system information block type for the 
system information block referenced by the referencing block; and (4) include a second 
system information block type extension indicator in the system information block type 

10 field of a segment of the system information block referenced by the referencing block. 

[00034] Responsive to this mode and method, the user equipment unit includes a 
system information processing function which is arranged and functions to accomplish 
the following: (1) recognize the first system information block type extension 
indicator in the system information block type field of the referencing block when the 

15 system information block type for the system information block referenced by the 
referencing block does not have a system information block type value in a nominal 
range of system information block type values; (2) locate the first system information 
block type extension field in the referencing block; (3) obtain from the first system 
information block type extension field a system information block type extension value 

20 which indicates a system information block type for the system information block 
referenced by the referencing block; and (4) recognize a second system information 
block type extension indicator in the system information block type field of a segment 
of the system information block referenced by the referencing block. 

[00035] As a variation of this mode and method, the system information processing 
25 function of the user equipment unit could skip processing the referencing block and 
essentially process only system information blocks, e.g., read the broadcast information 
continuously. This is feasible because the SIB type extension information is included 
in the segments of the system information blocks. In such variation, the system 
information processing function of the user equipment unit performs only the last three 
30 of the above enumerated operations. 
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[00036] In one non-limiting example of the foregoing embodiment and mode, the 
second system information block type extension indicator can have the same value as 
the first system information block type extension indicator. 

[00037] In another mode and method, the system information extension utility function 
is further arranged and further functions to include a second system information block 
type extension field in the segment of the system information block referenced by the 
referencing block; and include in the second system information block type extension 
field the system information block type extension value which indicates the system 
information block type for the system information block referenced by the referencing 
block. Concomitantly, the system information processing function of the user 
equipment unit for this mode and method locates the second system information block 
type extension field in the segment of the system information block referenced by the 
referencing block, and obtains from the second system information block type 
extension field the system information block type extension value which indicates the 
system information block type for the system information block referenced by the 
referencing block. 

[00038] In yet another mode and method, the system information extension utility 
function is arranged and functions to accomplish the following: (1) include, in a 
system information block type field of a system information block referenced by a 
referencing block, a system information block type value; and (2) include, in the 
referencing block, a code set identifier which identifies a selected one of plural code 
sets for use in interpreting the system information block type value included in the 
system information block type field of the system information block referenced by the 
referencing block. For example, a first value for the code set identifier can require that 
the system information block type value be interpreted in accordance with a range of 
nominal system information block type values for a predetermined protocol, while a 
second value for the code set identifier can require that the system information block 
type value be interpreted in accordance with a range of extended system information 
block type values, the extended system information block type values being outside the 
range of nominal system information block type values. The code set identifier can be 
included in an extension field of the referencing block. 
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[00039] In this yet another embodiment and mode, the system information processing 
function of the user equipment unit performs the following basic actions: (1) obtains, 
from the system information block type field of a system information block referenced 
by a referencing block, a system information block type value; (2) obtains, from the 

5 referencing block, a code set identifier which identifies a selected one of plural code 
sets; and (3), uses the selected one of the plural code sets for interpreting the system 
information block type value included in the system information block type field of the 
system information block referenced by the referencing block, as well as the (preferably 
same) the system information block type value included in the system information 

10 block type field of the referencing block. 

[00040] When the protocol blocks belong to a Radio Resource Control (RRC) protocol, 
the referencing block can be a master information block. In a master information block, 
the system information block type field is an "SIB and SB type" information element. 
Alternatively, in the Radio Resource Control (RRC) protocol the referencing block can 
15 be a scheduling block. For a scheduling block the system information block type field 
is an "SIB type SIBS only" information element. For an ordinary system information 
block, the system information block type field is a "SIB Type" information element. 

BMP DEgCMPTIOM OF THE DRAWINGS 

[00041] The foregoing and other objects, features, and advantages of the invention will 
20 be apparent from the following more particular description of preferred embodiments as 
illustrated in the accompanying drawings in which reference characters refer to the 
same parts throughout the various views. The drawings are not necessarily to scale, 
emphasis instead being placed upon illustrating the principles of the invention. 

[00042] Fig. 1 is a diagrammatic view of an example mobile communications system. 

25 [00043] Fig. 2 is a simplified function block diagram of a portion of a UMTS 

TeiTestrial Radio Access Network, including a user equipment unit (UE) station; a radio 
network controller; and a base station. 



[00044] Fig. 3 is a diagrammatic view of referencing block and a system information 
block generated according to a first embodiment and a first mode. 
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[00045] Fig. 3A is a diagrammatic view showing a variation of the referencing block 
and the system information block of Fig. 3. 

[00046] Fig. 4 is a flowchart showing basic example steps performed by a system 
information extension utility function of a network node for generating the referencing 
block and the system information block of Fig. 3. 

[00047] Fig. 5 is a diagrammatic view of an example format of a system information 
block such as the system information block of Fig. 3. 

[00048] Fig. 6 is a flowchart showing basic example steps performed by a system 
information processing function of a user equipment unit for processing the referencing 
block and the system information block of Fig. 3. 

[00049] Fig. 6A is a flowchart showing a variation of the processing steps of Fig. 6 
performed by a system information processing function of a user equipment unit 

[00050] Fig. 7 is a diagrammatic view of referencing block and a system information 
block generated according to a second embodiment and a second mode. 

[00051] Fig. 8 is a flowchart showing basic example steps performed by a system 
information extension utility function of a network node for generating the referencing 
block and the system information block of Fig. 7. 

[00052] Fig. 9 is a flowchart showing basic example steps performed by a system 
information processing function of a user equipment unit for processing the referencing 
block and the system information block of Fig. 7. 

[00053] Fig. 10 is a diagrammatic view of referencing block and a system information 
block generated according to a third embodiment and a third mode. 

[00054] Fig. 1 1 is a flowchart showing basic example steps performed by a system 
information extension utility function of a network node for generating the referencing 
block and the system information block of Fig. 10. 
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[00055] Fig. 12 is a flowchart showing basic example steps performed by a system 
information processing function of a user equipment unit for processing the referencing 
block and the system information block of Fig. 10. 

[00056] Fig. 13 is a diagrammatic view of an example format of a master information 
block. 

[00057] Fig. 14 is a diagrammatic view of an example format of a scheduling block. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[00058] In the following description, for purposes of explanation and not limitation, 
specific details are set forth such as particular architectures, interfaces, techniques, etc. 
in order to provide a thorough understanding of the present invention. However, it will 
be apparent to those skilled in the art that the present invention may be practiced in 
other embodiments that depart from these specific details. In other instances, detailed 
descriptions of well-known devices, circuits, and methods are omitted so as not to 
obscure the description of the present invention with unnecessary detail. Those skilled 
in the art will appreciate that the functions may be implemented using individual 
hardware circuits, using software functioning in conjunction with a suitably 
programmed digital microprocessor or general purpose computer, using an application 
specific integrated circuit (ASIC), and/or using one or more digital signal processors 
(DSPs). 

[00059] An illustrative, non-limiting example of the radio access network embodiment 
alluded to above is now described in the context of a universal mobile 
telecommunications (UMTS) 13 shown in Fig. 1. A representative, connection- 
oriented, external core network, shown as a cloud 14 may be for example the Public 
Switched Telephone Network (PSTN) and/or the Integrated Services Digital Network 
(ISDN). A representative, connectionless-oriented external core network shown as a 
cloud 16, may be for example the Internet. Both core networks are coupled to their 
corresponding core network service nodes. The PSTN/ISDN connection-oriented 
network 14 is connected to a connection-oriented service node shown as a Mobile 
Switching Center (MSC) node 18 that provides circuit-switched services. The Internet 
connectionless-oriented network 16 is connected to a General Packet Radio Service 
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(GPRS) node 20 tailored to provide packet-switched type services which is sometimes 
referred to as the serving GPRS service node (SGSN). 

[00060] Each of the core network service nodes 18 and 20 connects to a UMTS 
Terrestrial Radio Access Network (UTRAN) 24 over a radio access network (RAN) 
5 interface referred to as the Iu interface. UTRAN 24 includes one or more radio network 
controllers (RNCs) 26. For sake of simplicity, the UTRAN 24 of Fig. 1 is shown with 
only two RNC nodes, particularly RNC 26! and RNC 262. Each RNC 26 is connected 
to a plurality of base stations (BS) 28. For example, and again for sake of simplicity, 
two base station nodes are shown connected to each RNC 26. In this regard, RNC 26i 

10 serves base station 28 M and base station 28i_ 2 , while RNC 262 serves base station 28 2 -i 
and base station 282-2. It will be appreciated that a different number of base stations can 
be served by each RNC, and that RNCs need not serve the same number of base 
stations. Moreover, Fig. 1 shows that an RNC can be connected over an Iur interface to 
one or more other RNCs in the URAN 24. Further, it will be appreciated by those 

15 skilled in the art that base station nodes have, in some contexts, more recently become 
known as Node B or B-nodes. 

[00061] In the illustrated embodiments, for sake of simplicity each base station 28 is 
shown as serving one cell. Each cell is represented by a circle which surrounds the 
respective base station. It will be appreciated by those skilled in the art, however, that a 
20 base station may serve for communicating across the air interface for more than one 
cell. For example, two cells may utilize resources situated at the same base station site. 

[00062] A user equipment unit (UE), such as user equipment unit (UE) 30 shown in 
Fig. 1, communicates with one or more cells or one or more base stations (BS) 28 over 
a radio or air interface 32. Each of the radio interface 32, the Iu interface, the Iub 
25 interface, and the Iur interface are shown by dash-dotted lines in Fig. 1. 

[00063] Fig. 2 shows selected general aspects of user equipment unit (UE) 30 and 
illustrative nodes such as radio network controller 26 and base station 28. The user 
equipment unit (UE) 30 shown in Fig. 2 includes a data processing and control unit 31 
for controlling various operations required by the user equipment unit (UE). The UE's 
30 data processing and control unit 31 provides control signals as well as data to a radio 
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transceiver 33 connected to an antenna 35. The radio transceiver 33 is a function of the 
physical layer. 

[00064] The example radio network controller 26 and base station 28 as shown in Fig. 
2 are radio network nodes that each include a corresponding data processing and 
5 control unit 36 and 37, respectively, for performing numerous radio and data processing 
operations required to conduct communications between the RNC 26 and the user 
equipment units (UEs) 30. Part of the equipment controlled by the base station data 
processing and control unit 37 includes plural radio transceivers 38 connected to one or 
more antennas 39. 

10 [00065] Described herein are embodiments of nodes of a telecommunications network 
which prepare network system information for transmission across an air interface to a 
user equipment unit, as well as methods of operating such node and embodiments of 
user equipment units which receive and process the system information. To this end, 
and generically representing all such embodiments and methods, Fig. 1 shows RNC 26 1 

15 as including an RRC entity 50-RAN while user equipment unit 30 includes a 

corresponding RRC entity 50-UE. Fig. 1 further shows that the RRC entity 50-RAN 
prepares system information which is transmitted in the manner depicted by arrow 52 to 
the user equipment unit 30 where it is processed by RRC entity 50-UE. 

[00066] The embodiments of the RRC entity 50-UE described herein facilitate the use 
20 of extended system information block types, e.g., the use of system information block 
type values which are outside a range of nominal system information block type values. 
For sake of consistency and simplicity, the particular aspect of the RRC entity 50-RAN 
which facilitates such use of extended system information block types will be referred 
to as a system information extension utility function and is illustrated by system 
25 information extension utility function 100 in Fig. 2. In one example, non-limiting 
implementation, the system information extension utility function 100 is included as 
part of the data processing and control unit 36 of radio network controller (RNC) node 
26. It will be appreciated that this aspect of RRC entity 50-RAN could be 
denominated by various other names, such as a system information scheduling function 
30 or the like. Moreover, it should be understood that the system information extension 
utility function 100 can be realized in other ways than as part of the data processing and 
control unit 36, and that the data processing and control unit 36 is not limited to one 
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particular processor or circuit. For example, the system information extension utility 
function 100 could be realized by using individual hardware circuits, using software 
functioning in conjunction with a suitably programmed digital microprocessor or 
general purpose computer, using an application specific integrated circuit (ASIC), 
5 and/or using one or more digital signal processors (DSPs). 

[00067] In like manner, the aspect of RRC entity 50-UE which detects and processes 
the extended system information block types is (for simplicity) called a system 
information processing function and is illustrated as system information processing 
function 102 in Fig. 2. In the particular example implementation shown, the system 
10 information processing function 102 is hosted by the data processing and control unit 
31 of user equipment unit 30. This particular name is not limiting, and its variety of 
possible implementations are similar to those above described with reference to the 
system information extension utility function 100 of RRC entity 50-RAN. 

[00068] Below described are three possible, non-limiting, example embodiments and 
15 corresponding operational modes for adding new system information blocks. In terms 
of network and user equipment unit (UE) hardware, each of these embodiments and 
modes can be described by the generic illustrations of Fig. 1 and Fig. 2. For each 
embodiment/mode, the system information includes a system information block type 
which is included in protocol blocks. The protocol blocks include a system information 
20 block and a referencing block. In accordance with one particular kind of protocol, i.e., 
Radio Resource Control (RRC) protocol, the referencing block is one or both of a 
master information block and a scheduling block. The protocol blocks in which the 
system information is included have a system information block type field. The system 
information block type field includes a system information block type value which 
25 corresponds to the system information block type. The system information block can 
comprise one or more segments. 

[00069] FIRST EMBODIMENT/MODE: Artificial extension within SIB-data field of 
segments 



30 



[00070] An example of the first embodiment/mode is illustrated in Fig. 3, which shows 
both a referencing block 1 10(3) and a system information block 1 12(3) generated by 
the system information extension utility function 100. Among its various fields, the 
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referencing block 1 10(3) includes a SIB type field 1 13(3). The system information 
block 1 12(3) is shown as having a segment 1 14(3). The segment 1 14(3) includes both a 
SIB type field 1 16(3) and a segment data field 1 18(3). Depending on the particular 
system information block (SIB) involved, there may be none, one, or more than one 
5 segments. For sake of convenience, only one segment 114(3) is shown in Fig. 3 and 
comparable illustrations referenced herein. Yet it should be understood that operations 
and/or formatting described herein with respect to one segment can occur with respect 
to plural segments in a system information block (SIB). 

[00071] For extended SIB types both within referencing block 1 10(3) and within the 
io segments 1 14 the SIB type field 1 16(3) is set to a special value, e.g., 4 1 1 1 TB, 

indicating that it concerns an extended SIB type. This special value ensures that the 
SIB will be ignored by mobiles (e.g., user equipment units) which do not support this 
extension. Moreover, within the referencing block 110(3) a regular extension is added. 
This extension includes an additional SIB type extension field 120(3) which is used to 
15 distinguish a number of additional SIB types. Within the segments 1 14(3) a similar 
additional field is introduced, e.g., SIB type extension field 122(3). As shown in Fig. 3, 
the SIB type extension field 122(3) is created within the original SIB data field 118(3). 

[00072] Fig. 3 A shows a slight variation of the embodiment of Fig. 3. Fig. 3 A shows 
the SIB type extension field 120(3) as being part of an extension to the referencing 
20 block 1 10(3A). Other embodiments/modes described herein can be comparably varied 
in the manner depicted in Fig. 3 A. 

[00073] Normally the SIB data field 118 only carries the real payload (part of) a system 
information block. The format of a system information block (SIB) for the first 
embodiment is further illustrated Fig. 5. In Fig. 5, the information element ,f SIB type" 
25 corresponds to the SIB type field 1 16(3); the information element "SIB data fixed 
extension" corresponds to the segment data field 118(3); and, the information element 
"SIB type extension" corresponds to the SIB type extension field 122(3). 

[00074] Fig. 4 shows basic, example actions implemented by system information 
extension utility function 100 in conjunction with the first embodiment/mode. Action 
30 4-1 through action 4-3 are actions performed by system information extension utility 
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function 100 with reference to referencing block 1 10(3); action 4-4 through 4-6 are 
performed with reference to system information block 1 12(3). 

[00075] As action 4-1 the system information extension utility function 100 includes a 
first system information block type extension indicator (e.g., the value "1111") in the 

5 system information block type field 1 13(3) of the referencing block 1 10(3) when the 
system information block type for a system information block referenced by the 
referencing block does not have a system information block type value in a nominal 
range of system information block type values. Then, as action 4-2, the system 
information extension utility function 100 includes the first system information block 

10 type extension field 120(3) in the referencing block 1 10(3). As action 4-3 the system 
information extension utility function 100 includes, in the first system information 
block type extension field 120(3), a system information block type extension value 
which indicates a system information block type for the system information block (e.g., 
system information block 1 12(3)) referenced by the referencing block. 

15 [00076] As action 4-4, the system information extension utility function 100 includes a 
second system information block type extension indicator in the system information 
block type field 1 16(3) of the segment 1 14 of the system information block referenced 
by the referencing block, i.e., system information block 1 12(3). Preferably but not 
necessarily, in one non-limiting example of the foregoing embodiment and mode, the 

20 second system information block type extension indicator can have the same value as 
the first system information block type extension indicator (e.g., "11 11"). 

[00077] As action 4-5, the system information extension utility function 100 includes 
the second system information block type extension field 122(3) in the segment 1 14 of 
the system information block referenced by the referencing block, i.e., system 
25 information block 1 12(3). Further, as action 4-6, the system information extension 
utility function 100 includes in the second system information block type extension 
field 122(3) the system information block type extension value which indicates the 
system information block type for the system information block referenced by the 
referencing block (referencing block 110(3)). 

30 [00078] Fig. 6 shows basic example steps performed by a system information 

processing function 102 of user equipment unit 30 for processing the referencing block 
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1 10(3) and the system information block 1 12(3) of Fig. 3. Action 6-1 through action 6- 
3 are performed by system information processing function 102 with reference to 
referencing block 1 10(3); action 6-4 through 6-6 are performed with reference to 
system information block 1 12(3). 

5 [00079] As action 6-1, the system information processing function 102 recognizes the 
first system information block type extension indicator in the system information block 
type field 1 13(3) of the referencing block 1 10(3) when the system information block 
type for the system information block referenced by the referencing block does not 
have a system information block type value in a nominal range of system information 

10 block type values. As action 6-2 the system information processing function 102 

locates the first system information block type extension field 120(3) in the referencing 
block 1 10(3). As action 6-3 the system information processing function 102 obtains 
from the first system information block type extension field 120(3) a system 
information block type extension value which indicates a system information block 

15 type for the system information block referenced by the referencing block, i.e., system 
information block 1 12(3). 

[00080] As action 6-4 the system information processing function 102 recognizes a 
second system information block type extension indicator in the system information 
block type field 1 16(3) of the segment 1 14 of the system information block referenced 

20 by the referencing block, i.e., system information block 1 12(3). Then, as action 6-5, the 
system information processing function 102 locates the second system information 
block type extension field 122(3) in the segment of the system information block 
referenced by the referencing block. As action 6-6 the system information processing 
function 102 obtains from the second system information block type extension field . 

25 122(3) the system information block type extension value which indicates the system 
information block type. The system information processing function 102 can then 
process the system information block 1 12(3) in accordance with its type. 

[00081] As a variation of the first embodiment/mode, the system information 
processing function of the user equipment unit could skip processing the referencing 
30 block and essentially process only system information blocks, e.g., read the broadcast 
information continuously. This is feasible because the SIB type extension information 
is included in the segments of the system information blocks and can be used to decode 
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the information. Such variation is illustrated in Fig. 6A, wherein the system 
information processing function of the user equipment unit performs only action 6-4, 
action 6-5, and action 6-6, all as understood with reference to the Fig. 6 description 
thereof. In other words, in this variation actions 6-1 through 6-3 (e.g., the 
5 reading/processing of the referencing block) are not performed by the system 
information processing function of the user equipment unit. 

[00082] For the first embodiment/mode, receivers not supporting the extension will just 
ignore segments corresponding with extended SIB types (based on the value 'llll'B 
within the SIB-type field). This means that the first embodiment/mode is fully 
10 backwards compatible. 

[00083] Receivers supporting the extensions should be able to decode the SIB data and 
know that the first bits actually concern the SIB type extension. This can be done by 
making the IE SIB type extension conditional on the value of SIB type; it is included if 
SIB type has value "Reserved for extension". 

15 [00084] The foregoing can be implemented in the language which is utilized for 
making abstract notation for the particular protocol involved. In the Radio Resource 
Control (RRC) protocol the Abstract Syntax Notation One (ASN.l) language, an ITU 
standard, is utilized. See, ITU-T Recommendation X.680 (12/97) "Information 
Technology - Abstract Syntax Notation One (ASN.l): Specification of Basic Notation; 

20 and ITU-T Recommendation X.681 (12/97) "Information Technology - Abstract Syntax 
Notation One (ASN.l): Information Object Specification. In the ASN.l, the foregoing 
can be implemented as follows: 



25 



FirstSegment::= 
- Other information elements 
sib-TypeAndFirstSegment 



SEQUENCE { 



SIB-TypeAndFirstSegment 



SIB-TypeAndFirstSegment ::= 
MasterlnformationB lock 



NormalFirstSegment, 
NormalFirstSegment, 
NormaLFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 
NormalFirstSegment, 



CHOICE { 



30 



sy stemlnformationB lockType 1 
sy stemlnformationB lockType2 
systemInformationBlockType3 
systemInformationBlockType4 
systemInformationBlockType5 
systemInformationBlockType6 
systemInformationBlockType7 
systemInformationBlockType8 
systemInformationBlockType9 



35 
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10 



15 



20 



25 



30 



35 



systemlnfonnationBlockTypelO 

systemlnforraationBlockTypel 1 

systemInformationBlockTypel2 

systemInformationBIockTypel3 

systemlnformationB IockType 1 3- 1 

systemlnformationB IockType 1 3-2 

systemInformationBiockTypel3-3 

systemlnformationB IockType 13-4 

systemlnformationB IockType 14 

systemlnformationBlockType 1 5 

systemlnformationB IockType 15- 1 

systemInformationBlockTypel5-2 

systemInformationBlockTypel5-3 

systemlnformationBlockTypel 6 

systemInformationBIockTypel7 

systemInformationBlockTypel5-4 

systemInformationBiockTypel8 

scheduIingBIockl 

schedu!ingBlock2 

systemInformationBlockTypel5-5 

systemInformationBlockTypel9 

reservedForExtension 



} 



NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 

NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 
NormaiFirstSegment, 

NormaiFirstSegment, 
NormaiFirstSegment, 
ExtendedFirstSegment 



ExtendedFirstSegment ::= SEQUENCE { 

- Other information elements 

seg-Count 

sib-TypeExt 

sib-Data-fixed2 

} 

NormaiFirstSegment ::= SEQUENCE { 

- Other information elements 

seg-Count 
sib-Data-fixed 

) 



SegCount, 

SIB-TypeExt, 

SIB-Data-ilxed2 



SegCount, 
SIB-Data-fixed 



[00085] It should be noted that the scheduling of system information has been 
optimised so that in case a segment takes an entire transfer block (TB) no size 

40 information is included. This is implemented by means of separate values for the 

CHOICE parameter "Segmentation combination". This has resulted in a large number 
of ASN.l definitions, mainly for the purpose of size optimization. The use of the above 
approach would not only significantly increase the large number of ASN.l lines but 
also further increases the scheduling complexity (since the number of payload bits is 

45 different for an extended SIB due to the additional SIB type extension field). 



[00086] The previously mentioned significant increase in ASN.l lines could be avoided 
by not explicitly reflecting in the ASN.l the presence of the SIB-TypeExt at the start of 
SIB-Data, e.g., by just inserting a comment. However, this also involves inclusion of 
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additional SIB-type information in every segment, which implies that the overhead 
increases. 

[00087] SECOND EMBODIMENT/MODE: Extended SIB- type details only in 
scheduling information 

5 [00088] An example of the second embodiment/mode is illustrated in Fig. 7, which 
shows both a referencing block 1 10(4) and a system information block 112(4) 
generated by the system information extension utility function 100. Fields which are 
common with the embodiment of Fig. 3 are comparably numbered (with the exception 
of parenthetical suffixes) and comparably understood with reference to the embodiment 

10 of Fig. 3. 

[00089] In the second embodiment/mode of Fig. 7 , for extended SIB types both within 
the referencing block 1 10(4) and within the segments 1 14 of the system information 
block 1 12(4) the SIB type is set to a special value, e.g., 'lllTB, indicating that it 
concerns an extended SIB type. In particular, both the SIB type field 1 13(4) of 

15 referencing block 1 10(4) and the SIB type field 1 16(4) of the system information block 
112(4) are set to the special value. This ensures that the system information block 
1 12(4) will be ignored by mobile stations (e.g., user equipment units (UEs)) which do 
not support this extension. Within the referencing block 1 10(4) a regular extension is 
added including the additional SIB type extension field 120(4), which is used to 

20 distinguish a number of additional SIB types. For instance, in case three bits are 

reserved for the SIB type extension field 120(4), an additional seven SIB types can be 
supported. In contrast to the first embodiment/mode, no such additional field is 
introduced with system information block 1 12(4). In other words, the second 
embodiment/mode differs from the first in that system information block 1 12(4) does 

25 not have a SIB type extension field 122(4). 

[00090] Fig. 8 shows basic, example actions implemented by system information 
extension utility function 100 in conjunction with the second embodiment/mode. 
Action 8-1 through action 8-4 of Fig. 8 are essentially the same as action 4-1 through 
action 4-4 of Fig. 4, and accordingly are not discussed herein. Fig. 8 omits any actions 
30 corresponding to actions 4-5 through 4-6 of Fig. 4. 
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[00091] Fig. 9 shows basic example steps performed by a system information 
processing function 102 of user equipment unit 30 for processing the referencing block 
1 10(3) and the system information block 1 12(3) of Fig. 7. Action 9-1 through action 9- 
4 of Fig. 9 are essentially the same as action 6-1 through action 6-4 of Fig. 6, and 
5 accordingly are not discussed herein. Fig. 9 omits any actions corresponding to actions 
6-5 through 6-6 of Fig. 6. 

[00092] The merits of the second embodiment/mode are as follows: the second 
embodiment/mode is still fully backwards compatible. Moreover, the second 
embodiment/mode is more efficient since it involves less overhead in every segment, 
10 and also avoids the explosion in ASN.l type definitions, and the existing scheduling 
algorithms are not affected. 

[00093] The second embodiment/mode requires an additional mechanism to allow the 
scheduling of multiple extended SIB type at the same time and within the same 
SYSTEM INFORMATION message. The details of which extended SIB type is 

15 included in a segment is included in the scheduling information. In case multiple 
extended SIB types are included in a SYSTEM INFORMATION message, the 
scheduling information should clarify the SIB type for each of those. This can be done 
by including additional information in the scheduling information or by defining a fixed 
rule, e.g., that the order used in the SYTEM INFORMATION message is the same as 

20 the one used in the scheduling information. 

[00094] THIRD EMBODIMENT/MODE Extended SIB- type details only in 
scheduling information 

[00095] An example of the third embodiment/mode is illustrated in Fig. 10, which 
shows both a referencing block 1 10(10) and a system information block 1 12(10) 
25 generated by the system information extension utility function 100. Fields which are 
common with the embodiment of Fig. 3 are comparably numbered (with the exception 
of parenthetical suffixes) and comparably understood with reference to the embodiment 
of Fig. 3. 

[00096] In the third embodiment of Fig. 10, for extended SIB types both within the 
30 referencing block 1 10(10) and within the segments 1 14 of the system information 
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block 112(10) the respective regular SIB type fields 1 13(10) and 116(10) are used to 
* distinguish the additional SIB types. Within the referencing block 1 10(10), a regular 
extension is added including an additional code set field 130(10), indicating how the 
SIB type should be interpreted. For example, a value 0 in the SIB type field would 
5 mean SIB type 1 if a first code set is operative (as indicated by the code set identifier in 
field 130(10)) and would mean SIB type 20 if a second code set is operative. In this 
third embodiment/mode, no additional fields are introduced or required within the 
segments of the system information block 1 12(10) . 

[00097] Preferably there is one code set field per referencing block or per block that is 
10 referenced to be scheduled. This avoids having different code sets being utilized for 
different system information blocks that are referenced by a referencing block. 

[00098] In contrast to the first embodiment/mode and the second embodiment/mode, 
the third embodiment/mode is not backwards compatible since the interpretation of a 
given SIB type depends on information provided in an extension that earlier mobiles do 

15 not support. As a result, these non-supporting mobiles will interpret the information 
incorrectly. The third embodiment/mode does not really require additional mechanisms 
to support scheduling of multiple extended SIB type at the same time; within the same 
SYSTEM INFORMATION message. The only restriction that applies for the third 
embodiment/mode is that SIBs with the same value within the SIB type field should not 

20 be scheduled together. This is not considered to be an acceptable restriction, that could 
anyhow be resolved in a manner as described for the second embodiment. 

[00099] Fig. 1 1 shows basic example steps performed by system information extension 
utility function 100 in conjunction with the third embodiment/mode. As action 11-1, 
the system information extension utility function 100 includes, in a system information 

25 block type field 1 16(10) of a system information block 1 12(10) referenced by a 

referencing block, a system information block type value. Further, as action 1 1-2 the 
system information extension utility function 100 includes, in the referencing block 
1 10(10), a code set identifier which identifies a selected one of plural code sets for use 
in interpreting the system information block type value included in the system 

30 information block type field 1 16(10) of the system information block referenced by the 
referencing block. The code set identifier is included in code set identifier field 
130(10). For example, a first value for the code set identifier can require that the 
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* system information block type value be interpreted in accordance with a range of 
nominal system information block type values for a predetermined protocol, while a 
second value for the code set identifier can require that the system information block 
type value be interpreted in accordance with a range of extended system information 
5 block type values, the extended system information block type values being outside the 
range of nominal system information block type values. The code set identifier field 
130(10) can be included in an extension field of the referencing block. 

[000100] Fig. 12 shows basic example steps performed by a system information 
processing function 102 of user equipment unit 30 for processing the referencing block 

10 1 10(10) and the system information block 1 12(10) of Fig. 10. As action 1 1-1, the 

system information processing function 102 obtains, from the system information block 
type field 1 16(10) of a system information block referenced by a referencing block, a 
system information block type value. As action 1 1-2, the system information 
processing function 102 obtains, from the referencing block 110(10), a code set 

15 identifier (from code set identifier field 130(10)) which identifies a selected one of 
plural code sets. As action 1 1-3, the system information processing function 102 uses 
the selected one of the plural code sets for interpreting the system information block 
type value included in the system information block type field 1 16(10) of the system 
information block referenced by the referencing block, as well as the (preferably same) 

20 the system information block type value included in the system information block type 
field 1 13(10) of the referencing block 1 10(10). 

[000101] When the protocol blocks belong to a Radio Resource Control (RRC) 
protocol, the referencing block can be a master information block or a scheduling 
block. Fig. 13 depicts certain aspects and information elements of a master information 
25 block, and references in parenthesis the pertinent sections of the Technical 

Specification 3GPPTS 25.331 V3.17.0 (2003-12) referring to those information 
elements. In a master information block, such as that shown in Fig. 13, the system 
information block type field is an "SIB and SB type" information element. 

[000102] Fig. 14 depicts certain aspects and information elements of a scheduling 
30 block, and references in parenthesis the pertinent sections of the Technical 

Specification 3GPP TS 25.331 V3.17.0 (2003-12) referring to those information 
elements. For a scheduling block the system information block type field is an "SIB 
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type SIBS only" information element. For an ordinary system information block, the 
system information block type field is a "SIB Type" information element. 

[000103] Accordingly, as utilized herein, it will be understood that the term system 
information block type field as utilized herein can correspond in terms of Technical 
Specification 3GPP TS 25.331 V3.17.0 (2003-12) to any one of the appropriate 
information elements above mentioned, e.g., the "SIB and SB type" information 
element; the "SIB type SIBS only" information element; or the "SIB Type" information 
element. 

[000104] The embodiments and modes described herein permit addition of new 
system information block types. All mechanisms provide clear and specific ways to 
add system information blocks, with each embodiment/mode having its own specific 
merits. 

[000 1 05] For example, in the first embodiment the segments can still be decoded 
and processed without considering the scheduling information. The second 
embodiment tends to be more efficient since it does not involve the additional overhead 
in every segment, since it avoids the explosion in ASN.l type definitions, and since it 
does not affect the existing scheduling algorithms. These same considerations 
applicable to the second embodiment are also valid for the third embodiment. No 
additional mechanism is required to support scheduling of multiple extended SIB type 
at the same time/ within the same SYSTEM INFORMATION message. 

[000106] While the invention has been described in connection with what is 
presently considered to be the most practical and preferred embodiment, it is to be 
understood that the invention is not to be limited to the disclosed embodiment, but on 
the contrary, is intended to cover various modifications and equivalent arrangements 
included within the spirit and scope of the appended claims. 



